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Session Initiation Protocol (SIP) Call Control - Transfer 


Status of This Memo 


This document specifies an Internet Best Current Practices for the 
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited. 
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This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


Abstract 


This document describes providing Call Transfer capabilities in the 
Session Initiation Protocol (SIP). SIP extensions such as REFER and 
Replaces are used to provide a number of transfer services including 
blind transfer, consultative transfer, and attended transfer. This 
work is part of the SIP multiparty call control framework. 
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Le 


Overview 


This document describes providing Call Transfer capabilities and 
requirements in SIP [RFC3261]. This work is part of the multiparty 
call control framework [CC-FRMWRK]. 


The mechanisms discussed here are most closely related to 
traditional, basic, and consultation hold transfers. 


This document details the use of the REFER method [RFC3515] and 
Replaces [RFC3891] header field to achieve call transfer. 


A User Agent (UA) that fully supports the transfer mechanisms 
described in this document supports REFER [RFC3515] and Replaces 
[RFC3891] in addition to RFC 3261 [RFC3261]. A User Agent should use 
a Contact URI that meets the requirements in Section 8.1.1.8 of RFC 
3261. A compliant User Agent supports the Target-Dialog header field 
[RFC4538]. 


Actors and Roles 


There are three actors in a given transfer event, each playing one of 
the following roles: 


Transferee: the party being transferred to the Transfer 
Target. 

Transferor: the party initiating the transfer. 

Transfer Target: the new party being introduced into a call with 


the Transferee. 


The following roles are used to describe transfer requirements and 
scenarios: 


Originator: wishes to place a call to the Recipient. This 
actor is the source of the first INVITE in a 
session, to either a Facilitator or a Screener. 


Facilitator: receives a call or out-of-band request from the 
Originator, establishes a call to the Recipient 
through the Screener, and connects the Originator 
to the Recipient. Typically, a Facilitator acts 
on behalf of the Originator. 
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Screener: receives a Call ultimately intended for the 
Recipient and transfers the calling party to the 
Recipient if appropriate. Typically, a Screener 
acts on behalf of the Recipient. 


Recipient: the party to which the Originator is ultimately 
connected. 


3. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


4. Requirements 


1. Any party in a SIP session must be able to transfer any other 
party in that session at any point in that session. 


2. The Transferor and the Transferee must not be removed from a 
session as part of a transfer transaction. 


At first glance, requirement 2 may seem to indicate 

that the user experience in a transfer must be 
significantly different from what a current Private Branch 
Exchange (PBX) or Centrex user expects. As the call flows 
in this document show, this is not the case. A client may 
preserve the current experience. In fact, without 

this requirement, some forms of the current 

experience (ringback on transfer failure, 

for instance) will be lost. 


3. The Transferor must know whether or not the transfer was 
successful. 
4. The Transferee must be able to replace an existing dialog with a 


new dialog. 


5. The Transferor and Transferee should indicate their support for 
the primitives required to achieve transfer. 


6. The Transferor should provide the Transfer Target and Transferee 


with information about the nature and progress of the transfer 
operation being attempted. 
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To meet this requirement, the transfer operation can 
be modeled as an ad hoc conference between three 
parties, as discussed in Section 9. 


5. Using REFER to Achieve Call Transfer 


A REFER [RFC3515] can be issued by the Transferor to cause the 
Transferee to issue an INVITE to the Transfer Target. Note that a 
successful REFER transaction does not terminate the session between 
the Transferor and the Transferee. If those parties wish to 
terminate their session, they must do so with a subsequent BYE 
request. The media negotiated between the transferee and the 
Transfer Target is not affected by the media that had been negotiated 
between the Transferor and the Transferee. In particular, the INVITE 
issued by the Transferee will have the same Session Description 
Protocol (SDP) body it would have if the Transferee had initiated 
that INVITE on its own. Further, the disposition of the media 
streams between the Transferor and the Transferee is not altered by 
the REFER method. 


Agents may alter a session's media through additional signaling. For 
example, they may make use of the SIP hold re-INVITE [RFC3261] or 
conferencing extensions described in the conferencing framework 
[RFC4353]. 


To perform the transfer, the Transferor and Transferee could reuse an 
existing dialog established by an INVITE to send the REFER. This 
would result in a single dialog shared by two uses -- an invite usage 
and a subscription usage. The call flows for this are shown in 
detail in Section 6.2. However, the approach described in this 
document is to avoid dialog reuse. The issues and difficulties 
associated with dialog reuse are described in [RFC5057]. 


Motivations for reusing the existing dialog include: 


1. There was no way to ensure that a REFER on a new dialog would 
reach the particular endpoint involved in a transfer. Many 
factors, including details of implementations and changes in 
proxy routing between an INVITE and a REFER could cause the REFER 
to be sent to the wrong place. Sending the REFER down the 
existing dialog ensured it got to the endpoint to which we were 
already talking. 


2. It was unclear how to associate an existing invite usage with a 
REFER arriving on a new dialog, where it was completely obvious 
what the association was when the REFER came on the INVITE 
usage” s dialog. 
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3. There were concerns with authorizing out-of-dialog REFERs. The 
authorization policy for REFER in most implementations piggybacks 
on the authorization policy for INVITE (which is, in most Cases, 
based simply on "I placed or answered this call"). 


Globally Routable UA URIs (GRUUs) [SIP-GRUU] can be used to address 
problem 1. Problem 2 can be addressed using the Target-Dialog header 
field defined in [RFC4538]. In the immediate term, this solution to 
problem 2 allows the existing REFER authorization policy to be 
reused. 


As a result, if the Transferee supports the target-dialog extension 
and the Transferor knows the Contact URI is routable outside the 
dialog, the REFER SHOULD be sent in a new dialog. If the nature of 
the Contact URI is not known or if support for the target-dialog 
extension is not known, the REFER SHOULD be sent inside the existing 
dialog. A Transferee MUST be prepared to receive a REFER either 
inside or outside a dialog. One way that a Transferor could know 
that a Contact URI is routable outside a dialog is by validation 
(e.g., sending an OPTIONS and receiving a response) or if it 
satisfies the properties described in the GRUU specification 
[SIP-GRUU]. 


This document does not prescribe the flows and examples precisely as 
they are shown, but rather the flows illustrate the principles for 
best practice for the transfer feature. The call flows represent 
well-reviewed examples of SIP usage to implement transfer with REFER, 
which are Best Common Practice according to IETF consensus. 


In most of the following examples, the Transferor is in the 
atlanta.example.com domain, the Transferee is in the 
biloxi.example.com, and the Transfer Target is in the 
chicago.example.com domain. 


6. Basic Transfer 


Basic Transfer consists of the Transferor providing the Transfer 
Target's contact to the Transferee. The Transferee attempts to 
establish a session using that contact and reports the results of 
that attempt to the Transferor. The signaling relationship between 
the Transferor and Transferee is not terminated, so the call is 
recoverable if the Transfer Target cannot be reached. Note that the 
Transfer Target's contact information has been exposed to the 
Transferee. The provided contact can be used to make new calls in 
the future. 
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The participants in a basic transfer SHOULD indicate support for the 
REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to 
INVITE, and OPTIONS messages. Participants SHOULD also indicate 
support for Target-Dialog in the Supported header field. 


The diagrams below show the first line of each message. The first 
column of the figure shows the dialog used in that particular 
message. In these diagrams, media is managed through re-INVITE 
holds, but other mechanisms (mixing multiple media streams at the UA 
or using the conferencing extensions, for example) are valid. 
Selected message details are shown labeled as message F1, F2, etc. 


Each of the flows below shows the dialog between the Transferor and 
the Transferee remaining connected (on hold) during the REFER 
process. While this provides the greatest flexibility for recovery 
from failure, it is not necessary. If the Transferor's agent does 
not wish to participate in the remainder of the REFER process and has 
no intention of assisting with recovery from transfer failure, it 
could emit a BYE to the Transferee as soon as the REFER transaction 
completes. This flow is sometimes known as "unattended transfer" or 
"plind transfer". 


Figure 1 shows transfer when the Transferee utilizes a GRUU and 
supports the target-dialog extension and indicates this to the 
Transferor. As a result, the Transferor sends the REFER outside the 
INVITE dialog. The Transferee is able to match this REFER to the 
existing dialog using the Target-Dialog header field in the refer 
which references the existing dialog. 
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6.1. Successful Transfer 
Transferor Transferee Transfer 
Target 
| INVITE F1 | | 
dialog1 |< EEE EEE | | 
| 200 OK F2 | | 
dialogl |------------------- >| | 
ACK 
dialogl |«------------------- | 
| INVITE (hold) | | 
dialogl |------------------- >| | 
| 200 OK | 
dialogl |< A A A A | | 
| ACK | | 
dialogl oe > | 
REFER F3 (Target-Dialog:1) 
dialog2 |------------------- > | | 
| 202 Accepted | | 
dialog2 |«------------------- | | 
| NOTIFY (100 Trying) F4 | 
dialog2 |«------------------- 
200 OK 
dialog2 |------------------- >| 
| | INVITE F5 
dialog3 | |. —/][------------------- > | 
| | 200 OK | 
dialog3 AAP AA ar 
| ACK | 
dialog3 | |.  —/------------------- > | 
| NOTIFY (200 OK) F6| | 
dialog2 |«------------------- | 
| 200 OK | | 
dialog2 |------------------- > 
| BYE | 
dialogl | =- >| 
| 200 OK | | 
dialogl |«------------------- | 
| | BYE 
dialog3 | PI AP nah a | 
200 OK 
dialog3 | EEE sata > | 


Figure 1: Basic Transfer Call Flow 
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F1 INVITE Transferee -> Transferor 


INVITE sips:transferor@atlanta.example.com SIP/2.0 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com> 

From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces, gruu, tdialog 

Contact: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2ha» 
Content-Type: application/sdp 

Content-Length: 


F2 200 OK Transferor -> Transferee 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 

To: <sips:transferor@atlanta.example.com>; tag=31kd14i3k 
From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces, gruu, tdialog 

Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 
Content-Type: application/sdp 

Content-Length: 


F3 REFER Transferor -> Transferee 


REFER sips:31d812adkjw@biloxi.example.com; gr=3413kj2ha SIP/2.0 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKna9 

Max-Forwards: 70 

To: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2hna» 

From: <sips:transferor@atlanta.example.com>; tag=1928301774 

Call-ID: a84b4c76e66710 

CSeq: 314159 REFER 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 

Supported: gruu, replaces, tdialog 

Require: tdialog 

Refer-To: <sips:transfertarget@chicago.example.com> 

Target-Dialog: 090459243588173445; local-tag=7553452 
;remote-tag-3lkdl4i3k 

Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 

Content-Length: 0 
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F4 NOTIFY Transferee -> Transferor 


NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 

Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com>; tag=1928301774 

From: <sips:31d812adkjw@biloxi.example.com; gr=3413kj2ha> 
;tag-a6c85cf 

Call-ID: a84b4c76e66710 

CSeq: 73 NOTIFY 

Contact: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2ha» 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 

Supported: replaces, tdialog 

Event: refer 

Subscription-State: active;expires=60 

Content-Type: message/sipfrag 

Content-Length: 


SIP/2.0 100 Trying 


F5 INVITE Transferee -> Transfer Target 


INVITE sips:transfertarget@chicago.example.com SIP/2.0 
Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas41234 
Max-Forwards: 70 

To: <sips:transfertarget@chicago.example.com> 

From: <sips:transferee@biloxi.example.com>;tag=j3kso3ighq 
Call-ID: 90422f3sd23m4g56832034 

CSeq: 521 REFER 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces, gruu, tdialog 

Contact: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha> 
Content-Type: application/sdp 

Content-Length: 
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F6 NOTIFY Transferee -> Transferor 


NOTIFY sips:4889445d8kjtk3Gatlanta.example.com;gr-723jd2d SIP/2.0 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 

Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com>; tag=1928301774 

From: <sips:31d812adkjw@biloxi.example.com; gr=3413kj2ha> 
;tag-a6c85cf 

Call-ID: a84b4c76e66710 

CSeq: 74 NOTIFY 

Contact: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2ha» 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 

Supported: replaces, tdialog 

Event: refer 

Subscription-State: terminated;reason-noresource 

Content-Type: message/sipfrag 

Content-Length: 


SIP/2.0 200 OK 

6.2. Transfer with Dialog Reuse 
In this scenario, the Transferor does not know the properties of the 
Transferee's Contact URI or does not know that the Transferee 


supports the Target-Dialog header field. As a result, the REFER is 
sent inside the INVITE dialog. 
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Transferor Transferee Transfer 
Target 
INVITE F1 
dialogl |«------------------- 
| 200 OK F2 | | 
dialogl |------------------- >| | 
| ACK | | 
dialogl |< —-—-—-----------===== | | 
INVITE (hold) | 
dialogl |------------------- > 
| 200 OK | | 
dialogl |< ——— ens | | 
| ACK | 
dialogl |------------------- > | | 
| REFER F3 | | 
dialog1 ----- > | 
202 Accepted 
dialogl |< pe ER ee eee | | 
| NOTIFY (100 Trying) F4 | 
dialog1 |< A A ES | | 
| 200 OK | | 
dialogl |------------------- > 
| INVITE F5 | 
dialog? | |  J|------------------- > 
| | 200 OK 
dialog2 | |<------------------- | 
| | ACK 
dialog? | J]J|-2------------------ > 
| NOTIFY (200 OK) F6 
dialogl |«------------------- | 
| 200 OK | | 
dialogl |------------------- >| | 
| BYE | | 
dialogl | ------ > | 
200 OK 
dialogl |< e Juke | | 
| | BYE | 
dialog2 | |<------------------- | 
| | 200 OK | 
dialog2 | BESES tc > | 


Figure 2: Transfer with Dialog Reuse 
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F1 INVITE Transferee -> Transferor 


INVITE sips:transferor@atlanta.example.com SIP/2.0 
Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com> 

From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Contact: <sips:transferee@192.0.2.4> 

Content-Type: application/sdp 

Content-Length: 


F2 200 OK Transferor -> Transferee 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 

To: <sips:transferor@atlanta.example.com>; tag=31kd14i3k 
From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: gruu, replaces 

Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 
Content-Type: application/sdp 

Content-Length: 


F3 REFER Transferor -> Transferee 


REFER sips:transferee@192.0.2.4 SIP/2.0 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKna9 
Max-Forwards: 70 

To: «sips:transferee(biloxi.example.com»;tag-7553452 

From: <sips:transferor@atlanta.example.com>;tag=31kd14i3k 
Call-ID: 090459243588173445 

CSeq: 314159 REFER 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Refer-To: <sips:transfertarget@chicago.example.com> 
Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 
Content-Length: 0 
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F4 NOTIFY Transferee -> Transferor 


NOTIFY sips:4889445d8kjtk3Gatlanta.example.com;gr-723jd2d SIP/2.0 
Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com>; tag=31kd14i3k 
From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29888 INVITE 

Contact: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha> 
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Event: refer 

Subscription-State: active; expires=60 

Content-Type: message/sipfrag 

Content-Length: 


SIP/2.0 100 Trying 


F5 INVITE Transferee -> Transfer Target 


INVITE sips:transfertarget@chicago.example.com SIP/2.0 
Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas41234 
Max-Forwards: 70 

To: <sips:transfertarget@chicago.example.com> 

From: <sips:transferee@biloxi.example.com>;tag=j3kso3ighq 
Call-ID: 90422f3sd23m4g56832034 

CSeq: 521 REFER 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Contact: <sips:transferee@192.0.2.4> 

Content-Type: application/sdp 

Content-Length: 
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F6 NOTIFY Transferee -> Transferor 


NOTIFY sips:4889445d8kjtk3Gatlanta.example.com;gr-723jd2d SIP/2.0 
Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com>; tag=31kd14i3k 
From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29889 INVITE 

Contact: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha> 
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Event: refer 

Subscription-State: terminated; reason=noresource 
Content-Type: message/sipfrag 

Content-Length: 


SIP/2.0 200 OK 
6.3. Failed Transfer 


This section shows examples of failed transfer attempts. After the 
transfer failure occurs, the Transferor takes the Transferee off hold 
and resumes the session. 
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6.3.1. Target Busy 


Transferor Transferee Transfer 
al 
| 
| INVITE | | 
dialog1 |< EEE | | 
| 200 OK | | 
dialogl |------------------- > 
| ACK | 
dialogl |< Se a eee Se See | | 
| INVITE (hold) | | 
dialogl | aaa > | 
| 200 OK | | 
dialogl |< EE ee | | 
ACK 
dialogl |------------------- > 
| REFER (Target-Dialog:1) 
dialog2 |------------------- >| | 
| 202 Accepted | | 
dialog2 |«------------------- | | 
NOTIFY (100 Trying) 
dialog2 |«------------------- 
| 200 OK | 
dialog2 |------------------- > | 
| | INVITE | 
dialog3 | [------------------- > | 
| 486 Busy Here | 
dialog3 A AAA 
| | ACK | 
dialog3 | E >| 
| NOTIFY (486 Busy Here) | 
dialog2 |«------------------- | 
200 OK 
dialog2 ——————————————————— > | 
| INVITE (unhold) | 
dialogl |------------------- > | | 
| 200 OK | 
dialogl |«------------------- | 
ACK 
dialogl | oa > 
| BYE | | 
dialogl |------------------- >| | 
| 200 OK | 
dialogl |«------------------- | 


Figure 3: Failed Transfer - Target Busy 
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Transfer Target Does Not Answer 
Transferor Transferee Transfer 
| | Target 
| INVITE | | 
dialog1 |< zz... | | 
| 200 OK | | 
dialogl |------------------- > | | 
ACK 
dialogl |«------------------- | | 
| INVITE (hold) | | 
dialogl |------------------- >| | 
| 200 OK | 
dialogl |< POE EERTE eis Ee | | 
| ACK | | 
dialogl |------------------- > 
| REFER | 
dialog2 |------------------- > | | 
| 202 Accepted | | 
dialog2 |«------------------- | | 
| NOTIFY (100 Trying) | | 
dialog2 i ——— A 
200 OK 
dialog2 |------------------- > | 
| | INVITE 
dialog3 | pa an > | 
| 180 Ringing | 
dialog3 [«------------------- | 
(Transferee gets tired of waiting) 
| | CANCEL | 
dialog3 | EEE eae > | 
| | 200 OK (CANCEL) 
dialog3 | [estacas KAO | 
| 487 Request Cancelled (INVITE) 
dialog3 [«------------------- | 
| | ACK | 
dialog3 | pesce e > | 
| NOTIFY (487 Request Cancelled) 
dialog2 |«------------------- | 
200 OK 
dialog2 | ——————————————————— T 
| INVITE (unhold) | | 
dialogl |------------------- >| | 
| 200 OK | | 
dialog1 |< a... | | 
ACK 
dialog1 | ----- > 
| BYE | | 
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dialogi |------------------- > | | 
| 200 OK | | 
dialogl |< EE EE ss — | | 


Figure 4: Failed Transfer - Target Does Not Answer 

7. Transfer with Consultation Hold 
Transfer with consultation hold involves a session between the 
Transferor and the Transfer Target before the transfer actually takes 


place. This is implemented with SIP Hold and Transfer as described 
above. 


A nice feature is for the Transferor to let the target know that the 
session relates to an intended transfer. Since many UAs render the 
display name in the From header field to the user, a consultation 
INVITE could contain a string such as "Incoming consultation from 
Transferor with intent to transfer Transferee", where the display 
names of the transferor and transferee are included in the string. 


7.1. Exposing Transfer Target 


The Transferor places the Transferee on hold, establishes a call with 
the Transfer Target to alert them to the impending transfer, 
terminates the connection with the Transfer Target, then proceeds 
with transfer as above. This variation can be used to provide an 
experience similar to that expected by current PBX and Centrex users. 


To (hopefully) improve clarity, non-REFER transactions have been 


collapsed into one indicator with the arrow showing the direction of 
the request. 
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Transferor Transferee Transfer 
| | Target 


dialogl | INVITE/200 OK/ACK 


| <------------------- | 
dialogl | INVITE (hold) /200 OK/ACK 
Cece ea peace > | 
dialog2 | INVITE/200 OK/ACK | 
EE rte ra a A A al rd a dn ee a > 
dialog2 | BYE/200 OK | 
| eem meme >| 
dialog3 | REFER | 
| ------------------- >| | 
dialog3 | 202 Accepted | | 
| <------------------- | | 
dialog3 | NOTIFY (100 a 
< rar a a an a Se a pl VE a ey Sp Se 
dialog3 | 200 OK | 
|--================= >| | 
dialog4 | | INVITE/200 OK/ACK | 
| OS E >| 
dialog3 | NOTIFY (200 OK) | | 
« Hiwa —— ÁÁ————Ó— an 
dialog3 | 200 OK | 
|------------------- >| | 
dialogl | BYE/200 OK | | 
|--================= >| | 


dialog4 | 


Figure 5: Transfer with Consultation Hold - Exposing Transfer Target 
7.2. Protecting Transfer Target 


The Transferor places the Transferee on hold, establishes a call with 
the Transfer Target and then reverses their roles, transferring the 
original Transfer Target to the original Transferee. This has the 
advantage of hiding information about the original Transfer Target 
from the original Transferee. On the other hand, the Transferee’s 
experience is different than in current systems. The Transferee is 
effectively "called back" by the Transfer Target. 


One of the problems with this simplest implementation of a target 
protecting transfer is that the Transferee is receiving a new call 
from the Transfer Target. Unless the Transferee’s agent has a 
reliable way to associate this new call with the call it already has 
with the Transferor, it will have to alert the new call on another 
appearance. If this, or some other call-waiting-like UI were not 


Sparks, et al. Best Current Practice [Page 19] 


RFC 5589 SIP CC Transfer June 2009 


available, the Transferee might be stuck returning a Busy-Here to the 
Transfer Target, effectively preventing the transfer. There are many 
ways that correlation could be provided. The dialog parameters could 
be provided directly as header parameters in the Refer-To URI, for 
example. The Replaces mechanism [RFC3891] uses this approach and 
solves this problem nicely. 


For the flow below, dialogl means dialog identifier 1, and consists 
of the parameters of the Replaces header for dialog 1. In [RFC3891], 
this is the Call-ID, To-tag, and From-tag. 


Note that the Transferee's agent emits a BYE to the Transferor's 
agent as an immediate consequence of processing the Replaces header. 


The Transferor knows that both the Transferee and the Transfer Target 
support the Replaces header from the Supported: replaces header 
contained in the 200 OK responses from both. 


In this scenario, the Transferee utilizes a GRUU as a Contact URI for 
reasons discussed in Section 6.3. 


Note that the conventions used in the SIP Torture Test Messages 
[RFC4475] document are reused, specifically the «allOneLine» tag. 
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Transferor Transferee Transfer 
| | Target 


| INVITE/200 OK/ACK F1 F2 


dialogl 
| o | 
dialogl | INVITE (hold)/200 OK/ACK 
|------------------- >| | 
dialog2 | INVITE/200 OK/ACK F3 F4 | 
a a a a O gana NE E > 
dialog2 | INVITE (hold)/200 OK/ACK 
| ee >| 
dialog3 | REFER (Target-Dialog:2, 
| Refer-To:sips:Transferee?Replaces-1) F5| 
| >| 
dialog3 | 202 Accepted | | 
« — ————— Hr —— a — — —— M a —— 
dialog3 NOTIFY (100 Trying)| 
Jim | 
dialog3 | | 200 OK | 
ln ——————— >| 
dialog4 | INVITE (Replaces:dialog1)/200 OK/ACK F6 
< SSS SS Oe A € 
dialogl | BYE/200 OK 
[no | 
dialog3 | NOTIFY (200 OK) | | 
|<---------------------------------------- 
dialog3 | | 200 OK | 
WA AA A a AA A Se ee A A A A A a a A a > 
dialog2 | BYE/200 OK | 
|--=====m0mmn mn >| 
| (Transferee and target converse) 
dialog4 | | BYE/200 OK | 
| | >| 
Figure 6: Transfer Protecting Transfer Target 
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F1 INVITE Transferee -> Transferor 


INVITE sips:transferor@atlanta.example.com SIP/2.0 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com> 

From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces, gruu 

Contact: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2ha» 
Content-Type: application/sdp 

Content-Length: 


F2 200 OK Transferor -> Transferee 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 

To: <sips:transferor@atlanta.example.com>;tag=31431 
From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces, gruu, tdialog 

Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 
Content-Type: application/sdp 

Content-Length: 


F3 INVITE Transferor -> Transfer Target 


INVITE sips:transfertarget@chicago.example.com SIP/2.0 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transfertarget@chicago.example.com> 

From: <sips:transferor@atlanta.example.com>; tag=763231 
Call-ID: 592435881734450904 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: gruu, replaces, tdialog 

Require: replaces 

Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=3841i321w3> 
Content-Type: application/sdp 

Content-Length: 
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F4 200 OK Transfer Target -> Transferor 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnas432 
;received-192.0.2.1 

To: ssips:transfertarget#@chicago. example. com”, tag-9m2n3wq 

From: <sips:transferor@atlanta.example.com>; tag=763231 

Call-ID: 592435881734450904 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 

Supported: replaces, gruu, tdialog 

Contact: <sips:482n4z24kdg@chicago.example.com; gr=8594958> 

Content-Type: application/sdp 

Content-Length: 


F5 REFER Transferor -> Transfer Target 


REFER sips:482n4z24kdgGchicago.example.com;gr-8594958 SIP/2.0 
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnashds9 
Max-Forwards: 70 
To: <sips:482n4z24kdg@chicago.example.com; gr=8594958> 
From: <sips:transferor@atlanta.example.com>;tag=1928301774 
Call-ID: a84b4c76e66710 
CSeq: 314159 REFER 
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: gruu, replaces, tdialog 
Require: tdialog 
<allOneLine> 
Refer-To: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha 
?Replaces-090459243588173445$3Bto-tag$3D7553452$3Bfrom-tag$3D31431» 
«/allOneLine» 
Target-Dialog: 592435881734450904; local-tag=9m2n3wq 

; remote-tag=763231 
Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 
Content-Length: 0 
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F6 INVITE Transfer Target -> Transferee 


INVITE sips:31d812adkjw@biloxi.example.com; gr=3413kj2ha SIP/2.0 
Via: SIP/2.0/TLS client.chicago.example.com;branch-z9hG4bKnaslu84 
Max-Forwards: 70 

To: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2ha-» 

From: <sips:transfertarget@chicago.example.com>;tag=341234 
Call-ID: kmzwdle3d13d08 

CSeq: 41 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: gruu, replaces, tdialog 

Contact: <sips:482n4z24kdg@chicago.example.com; gr=8594958> 
Replaces: 090459243588173445;to-tag=7553452;from-tag=31431 
Content-Type: application/sdp 

Content-Length: 


7.3. Attended Transfer 


The Transferor places the Transferee on hold, establishes a call with 
the Transfer Target to alert them to the impending transfer, places 
the target on hold, then proceeds with transfer using an escaped 
Replaces header field in the Refer-To header. This is another common 
service expected by current PBX and Centrex users. 


The Contact URI of the Transfer Target SHOULD be used by the 
Transferor as the Refer-To URI, unless the URI is suspected or known 
to not be routable outside the dialog. Otherwise, the Address of 
Record (AOR) of the Transfer Target SHOULD be used. That is, the 
same URI that the Transferor used to establish the session with the 
Transfer Target should be used. In case the triggered INVITE is 
routed to a different User Agent than the Transfer Target, the 
Require: replaces header field SHOULD be used in the triggered 
INVITE. (This is to prevent an incorrect User Agent that does not 
support Replaces from ignoring the Replaces and answering the INVITE 
without a dialog match.) 


It is possible that proxy/service routing may prevent the triggered 
INVITE from reaching the same User Agent. If this occurs, the 
triggered invite will fail with a timeout, 403, 404, etc. error. The 
Transferee MAY then retry the transfer with the Refer-To URI set to 
the Contact URI. 
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Transferor Transferee Transfer 
| | Target 
dialogl | INVITE/200 OK/ACK a F2 

Sede’. agate cO aye oe | 
mixed s eue ie a | 
sl e å 
es AA >| 

| Refer-To:sips:TransferTarget?Replaces-2) F5 
seni» dog cte 7 | 
rl ea | 
a pen 203 | 

sr oe ee 
dialog2 | BYE/200 ox | i 
a ur eund Pg PUR A | 
nugis | n "o | 
ed : 
dialog4 | Mr GANG AE i BYE/200 OK | 
ME. TO 


Figure 7: Attended Transfer Call Flow 
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F1 INVITE Transferee -> Transferor 


INVITE sips:transferor@atlanta.example.com SIP/2.0 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com> 

From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces, gruu, tdialog 

Contact: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2ha» 
Content-Type: application/sdp 

Content-Length: 


F2 200 OK Transferor -> Transferee 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 

To: <sips:transferor@atlanta.example.com>;tag=31431 
From: <sips:transferee@biloxi.example.com>; tag=7553452 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces, gruu, tdialog 

Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 
Content-Type: application/sdp 

Content-Length: 


F3 INVITE Transferor -> Transfer Target 


INVITE sips:transfertarget@chicago.example.com SIP/2.0 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transfertarget@chicago.example.com> 

From: <sips:transferor@atlanta.example.com>; tag=763231 
Call-ID: 592435881734450904 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: gruu, replaces, tdialog 

Require: replaces 

Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=3841i321w3> 
Content-Type: application/sdp 

Content-Length: 
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F4 200 OK Transfer Target -> Transferor 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnas432 
;received-192.0.2.1 

To: ssips:transfertarget#@chicago. example. com”, tag-9m2n3wq 

From: <sips:transferor@atlanta.example.com>; tag=763231 

Call-ID: 592435881734450904 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 

Supported: replaces, gruu 

Contact: <sips:482n4z24kdg@chicago.example.com; gr=8594958> 

Content-Type: application/sdp 

Content-Length: 


F5 REFER Transferor -> Transferee 


REFER sips:31d812adkjw@biloxi.example.com; gr=3413kj2ha SIP/2.0 
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnashds9 
Max-Forwards: 70 
To: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2hna» 
From: <sips:transferor@atlanta.example.com>; tag=1928301774 
Call-ID: a84b4c76e66710 
CSeq: 314159 REFER 
Require: tdialog 
<allOneLine> 
Refer-To: <sips:482n4z24kdg@chicago.example.com; gr=8594958? 
Replaces-592435881734450904$3Bto-tag$3D9m2n3wq$3Bfrom-tag3D763231» 
«/allOneLine» 
Target-Dialog: 592435881734450904;local-tag-9m2n3wq 

; remote-tag-763231 
Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 
Content-Length: 0 
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F6 INVITE Transferee -> Transfer Target 


INVITE sips:482n4z24kdg@chicago.example.com; gr=8594958 SIP/2.0 
Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnaslu82 
Max-Forwards: 70 

To: <sips:482n4z24kdg@chicago.example.com; gr=8594958> 

From: <sips:transferee@biloxi.example.com>;tag=954 

Call-ID: kmzwdle3d13d08 

CSeq: 41 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: gruu, replaces, tdialog 

Contact: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha> 
Replaces: 592435881734450904;to-tag-9m2n3wq; from-tag=763231 
Content-Type: application/sdp 

Content-Length: 


7.4. Recovery When One Party Does Not Support REFER 


If protecting or exposing the Transfer Target is not a concern, it is 
possible to complete a transfer with consultation hold when only the 
transferor and one other party support REFER. Note that a 405 Method 
Not Allowed might be returned instead of the 501 Not Implemented 
response. 
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Transferor Transferee Transfer 
| | Target 
dialogl | INVITE/200 OK/ACK 
ee | 
sed S | 
mel ees TIE å 
DN >| 
| Refer-To:sips:TransferTarget?Replaces-2) 
sah e | 
EE a c 
MT CE >| 
EE SI UE | 
me X UE 
DEM MAGA ar 
dialog4 | NOTIFY (200 OK) l LAE | 
FE GE em 
se >| 
mie Nee EE | | 
"m P7200" pens i 
E Ln E 


Figure 8: Recovery When One Party Does Not Support REFER 


7.5. Attended Transfer When Contact URI Is Not Known to Route to a 
Unique User Agent 


It is a requirement of RFC 3261 that a Contact URI be globally 
routable even outside the dialog. However, due to RFC 2543 User 
Agents and some architectures (NAT/Firewall traversal, screening 
proxies, Application Layer Gateways (ALGs), etc.) this will not 
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As a result, the method of attended transfer 
7, and 8 SHOULD only be used if the Contact URI 


ble outside the dialog. 


Figure 9 shows such a scenario where the Transfer Target Contact URI 
ide the dialog, so the triggered INVITE is sent 
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Transferor 


dialogl | INVITE/ 


dialogl | INVITE 
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Figure 9: Attended Transfer Call Flow with a Contact URI Not Known to 
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F1 INVITE Transferor -> Transfer Target 


INVITE sips:transfertarget@chicago.example.com SIP/2.0 
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 
Max-Forwards: 70 

To: <sips:transfertarget@chicago.example.com> 

From: <sips:transferor@atlanta.example.com>; tag=763231 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Contact: <sips:transferor@pc33.atlanta.example.com> 
Content-Type: application/sdp 

Content-Length: 


F2 200 OK Transfer Target -> Transferee 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnas432 
;received-192.0.2.1 

To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq 

From: <sips:transferor@atlanta.example.com>; tag=763231 

Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 

Supported: replaces 

Contact: <sips:transfertarget@client.chicago.example.com> 

Content-Type: application/sdp 

Content-Length: 


F3 REFER Transferor -> Transferee 


REFER sips:transferee@192.0.2.4 SIP/2.0 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnashds9 
Max-Forwards: 70 

To: <sips:transferee@biloxi.example.com>;tag=a6c85cf 

From: <sips:transferor@atlanta.example.com>; tag=1928301774 
Call-ID: a84b4c76e66710 

CSeq: 314160 REFER 

<allOneLine> 

Refer-To: <sips:transfertarget@chicago.example.com?Replaces= 
090459243588173445$3Bto-tag$3D9m2n3wq$3Bfrom-tag$3D763231 
&Require=replaces> 

<allOneLine> 

Contact: <sips:transferor@pc33.atlanta.example.com> 
Content-Length: 0 
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F4 INVITE Transferee -> Transfer Target 


INVITE sips:transfertarget@chicago.example.com SIP/2.0 
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas1u82 
Max-Forwards: 70 

To: <sips:transfertarget@chicago.example.com> 

From: <sips:transferee@biloxi.example.com>;tag=954 
Call-ID: 20482817324945934422930 

CSeq: 42 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Contact: <sips:transferee@192.0.2.4> 

Replaces: 090459243588173445;to-tag-9m2n3wq; from-tag=763231 
Require: replaces 

Content-Type: application/sdp 

Content-Length: 


F5 NOTIFY Transferee -> Transferor 


NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com>; tag=1928301774 
From: <sips:transferee@biloxi.example.com>;tag=a6c85cf 
Call-ID: a84b4c76e66710 

CSeq: 76 NOTIFY 

Contact: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha> 
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Event: refer; id=98873867 

Subscription-State: terminated; reason=noresource 
Content-Type: message/sipfrag 

Content-Length: 


SIP/2.0 200 OK 


Figure 10 shows a failure case in which the AOR URI fails to reach 
the Transfer Target. As a result, the transfer is retried with the 
Contact URI, at which point it succeeds. 


Note that there is still no guarantee that the correct endpoint will 
be reached, and the result of this second REFER may also be a 
failure. In that case, the Transferor could fall back to unattended 
transfer or give up on the transfer entirely. Since two REFERS are 
sent within the dialog creating two distinct subscriptions, the 
Transferee uses the 'id' parameter in the Event header field to 
distinguish notifications for the two subscriptions. 
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Transferor Transferee Screening Transfer 
Proxy Target 
dialogl | INVITE/200 OK/ACK | | 
| <----------------- | | 
dialogl | INVITE (hold) /200 OK/ACK | 
|----------------- >| | | 
dialog2 | INVITE/200 OK/ACK F1 F2 | | 
t | ------------> 
dialog2 | INVITE (hold) /200 OK/ACK 
|-------------------------------- |------------ >| 
dialogl | REFER (Refer-To:sips:TargetAOR? | 
| Replaces-dialog2&Require-replaces) F3 | 
|----------------- >| | 
dialogl | 202 Accepted | | | 
< —— OE 
dialogi NOTIFY (100 Trying) 
| e | | 
dialogl | 200 OK | | 
|----------------- d | 
dialog3 | | INVITE (Replaces:dialog2, | 
| Require:replaces) /403/ACK | 
Bee d > | 
dialogl | NOTIFY (403 Forbidden) F4 | 
|<----------------- | | 
dialog1 | 200 OK | | 
EE >| | | 
dialogl O A O F5 
A > | 
dialogl | 202 Accepted | | 
|<----------------- | | | 
dialogl | NOTIFY (100 Trying) | 
| <---------~------- | | 
dialogl | 200 OK | 
gr A a a an ig A ee > 
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6 
oe >| > >| 
dialog2 | BYE/200 OK | | 
| E |<------------ | 
dialogl | NOTIFY (200 OK) F7 | | 
<----------------- | 
dialogl | 200 OK | | 
---------------=- >| | | 
dialogl | BYE/200 OK | | | 
— >| | | 
dialog3 | BYE/200 OK 
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Figure 10: Attended Transfer Call Flow with Non-Routable Contact URI 
and AOR Failure 


Fl INVITE Transferor -> Transfer Target 


INVITE sips:transfertarget@chicago.example.com SIP/2.0 
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76 
Max-Forwards: 70 

To: <sips:transfertarget@chicago.example.com> 

From: <sips:transferor@atlanta.example.com>; tag=763231 
Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Contact: <sips:transferor@pc33.atlanta.example.com> 
Content-Type: application/sdp 

Content-Length: 


F2 200 OK Transfer Target -> Transferee 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnas432 
;received-192.0.2.1 

To: <sips:transfertargettchicago.example.com>;tag=9m2n3wq 

From: <sips:transferor@atlanta.example.com>; tag=763231 

Call-ID: 090459243588173445 

CSeq: 29887 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 

Supported: replaces 

Contact: <sips:transfertarget@client.chicago.example.com> 

Content-Type: application/sdp 

Content-Length: 
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F3 REFER Transferor -> Transferee 


REFER sips:transferee@192.0.2.4 SIP/2.0 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnashds9 
Max-Forwards: 70 

To: «sips:transferee(biloxi.example.com»;tag-a6c85cf 

From: <sips:transferor@atlanta.example.com>; tag=1928301774 
Call-ID: a84b4c76e66710 

CSeq: 314159 REFER 

<allOneLine> 

Refer-To: <sips:transfertarget@chicago.example.com?Replaces= 
090459243588173445$3Bto-tag$3D9m2n3wq$3Bfrom-tag$3D763231 
&Require=replaces> 

«/allOneLine» 

Contact: <sips:transferor@pc33.atlanta.example.com> 
Content-Length: 0 


F4 NOTIFY Transferee -> Transferor 


NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com>; tag=1928301774 
From: <sips:transferee@biloxi.example.com>;tag=a6c85cf 
Call-ID: a84b4c76e66710 

CSeq: 74 NOTIFY 

Contact: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha> 
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Event: refer; id=314159 

Subscription-State: terminated; reason=noresource 
Content-Type: message/sipfrag 

Content-Length: 


SIP/2.0 403 Forbidden 
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F5 REFER Transferor -> Transferee 


REFER sips:transferee@192.0.2.4 SIP/2.0 

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bKnashds9 
Max-Forwards: 70 

To: «sips:transferee(biloxi.example.com»;tag-a6c85cf 

From: <sips:transferor@atlanta.example.com>; tag=1928301774 
Call-ID: a84b4c76e66710 

CSeq: 314160 REFER 

«allOneLine» 

Refer-To: <sips:transfertarget@client.chicago.example.com 
?Replaces-090459243588173445$3Bto-tag$3D9m2n3wq 
$3Bfrom-tag$3D763231> 

«/allOneLine» 

Contact: <sips:transferor@pc33.atlanta.example.com> 
Content-Length: 0 


F6 INVITE Transferee -> Transfer Target 


INVITE sips:transfertarget@client.chicago.example.com SIP/2.0 
Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnaslu82 
Max-Forwards: 70 

To: <sips:transfertarget@chicago.example.com> 

From: <sips:transferee@biloxi.example.com>;tag=954 

Call-ID: 20482817324945934422930 

CSeq: 42 INVITE 

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Contact: <sips:transferee@192.0.2.4> 

Replaces: 090459243588173445;to-tag-9m2n3wq; from-tag=763231 
Content-Type: application/sdp 

Content-Length: 
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F7 NOTIFY Transferee -> Transferor 


NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0 

Via: SIP/2.0/TLS 192.0.2.4;branch-z9hG4bKnas432 
Max-Forwards: 70 

To: <sips:transferor@atlanta.example.com>; tag=1928301774 
From: <sips:transferee@biloxi.example.com>;tag=a6c85cf 
Call-ID: a84b4c76e66710 

CSeq: 76 NOTIFY 

Contact: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha> 
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 

Event: refer; id=314160 

Subscription-State: terminated; reason=noresource 
Content-Type: message/sipfrag 

Content-Length: 


SIP/2.0 200 OK 


To prevent this scenario from happening, the Transfer Target SHOULD 
use a Contact URI that is routable outside the dialog, which will 
result in the call flow of Figure 7. 


7.6. Semi-Attended Transfer 


In any of the consultation hold flows above, the Transferor may 
decide to terminate its attempt to contact the Transfer Target before 
that session is established. Most frequently, that will be the end 
of the scenario, but in some circumstances, the Transferor may wish 
to proceed with the transfer action. For example, the Transferor may 
wish to complete the transfer knowing that the Transferee will end up 
eventually talking to the Transfer Target’s voicemail service. Some 
PBX systems support this feature, sometimes called "semi-attended 
transfer", that is effectively a hybrid between a fully attended 
transfer and an unattended transfer. A call flow is shown in Figure 
11. In this flow, the Transferor’s User Agent continues the transfer 
as an attended transfer even after the Transferor hangs up. Note 
that media must be played to the Transfer Target upon answer -- 
otherwise, the Target may hang up and the resulting transfer 
operation will fail. 
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Transferor Transferee Transfer 
| | Target 
dialogl | INVITE/200 OK/ACK F1 F2 | 
«----------2-2------- | 
dialog1 | INVITE (hold)/200 OK/ACK | 
Srpna at a ee Ó— > | | 
dialog2 | INVITE | | 
EV ne EE a a ma n E > 
dialog2 | 180 Ringing 
| <---------------------------------------- 


Transferor hangs up but wants transfer to continue 


| User Agent continues transfer operation | 


dialog2 | 200 OK | 
< A E A A A ft i d it A d e te Fi A 
dialog2 | ACK | | 
| ----------~----------------------------- >| 
dialog2 | Media Played to keep Target from hanging up 
| >| 
dialog3 REFER (Target-Dialog:1, | 
Refer-To:sips:TransferTarget?Replaces-2) 
|------------------- >| | 
dialog3 | 202 Accepted | | 
|<------------------- | | 
dialog3 | NOTIFY (100 Trying) | 
< A Se rui qe cs Mie qucd ey d pur a ee a 
dialog3 200 OK 
| —- >| | 
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK 
| p >| 
dialog2 | BYE/200 OK | 
< EE ME de A a a a Ta an 
dialog3 NOTIFY (200 OK) | | 
|<------------------- | | 
dialog3 | 200 OK | 
A E > | | 
dialogl | BYE/200 OK | | 
——————————Á— — > 
dialog4 | BYE/200 OK | 
| [<-----------------=- | 


Figure 11: Recommended Semi-Attended Transfer Call Flow 
Two other possible semi-attended transfer call flows are shown in 


Figures 12 and 13. However, these call flows are NOT RECOMMENDED due 
to race conditions. In both of these flows, when the Transferor 
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hangs up, the Transferor attempts to revert to unattended transfer by 
sending a CANCEL to the target. This can result in two race 
conditions. One is that the target answers despite the CANCEL and 
the resulting unattended transfer fails. This race condition can be 
eliminated by the Transferor waiting to send the REFER until the 487 
response from the target is returned. Instead of a 487, a 200 OK may 
be returned indicating that the target has answered the consultation 
call. In this case, the call flow in Figure 13 must be followed. In 
this flow, the Transferor must play some kind of media to the Target 
to prevent the Target from hanging up, or the transfer will fail. 
That is, the human at the Transfer Target will hear silence from when 
they answer (message F1) until the transfer completes (F3 and they 
are talking to the Transferee unless some media is played (F2)). 


The second race condition occurs in Figure 12 if the Transfer Target 
goes "off hook" after the CANCEL is received and the 487 returned. 
This may result in a 486 Busy Here response to the unattended 
transfer. 


The recommended call flow of Figure 11 does not utilize a CANCEL and 
does not suffer from these race conditions. 
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Transferor Transferee Transfer 
Target 

dialogl | INVITE/200 OK/ACK 

«---------2-2-------- | 
dialogl | INVITE (hold)/200 OK/ACK | 

He Sa sadannan a > | | 
dialog2 | INVITE | 

a AN Pa E Ed rid att > 
dialog2 180 Ringing 

LS aan | 


dialog2 CANCEL 

var í 
EE | 
dialog2 per A a | 
a pe uomo å 
PEN I ost a | 
FE AN | 
entere "o 
dialog4 |o ETE OK/ACK | 
dialog3 | NOTIFY (200 OK) AIN E >| 
desse AA | | 
o UR. él | 
er i BYE/200 OK | 


Figure 12: Semi-Attended Transfer as Blind Transfer Call Flow (Not 
Recommended) 
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Transferor Transferee Transfer 


dialogl 
dialogl 
dialog2 


dialog2 


dialog2 
dialog2 
dialog2 
dialog2 


dialog2 


dialogl 


dialogl 
dialogl 
dialogl 
dialog3 
dialog2 
dialogl 
dialogl 
dialogl 


dialog3 


et al. 


Target 


| INVITE/200 OK/ACK 


^ 
i 
| 
l 
| 
l 
| 
l 
| 
| 
| 
l 
| 
l 
| 
| 
l 
| 
l 


|Transferor gives up waiting but Target answers 


| CANCEL | 
AA A A A A A AA AA AA A A! Se E > 
200 OK (CANCEL) 
|<---------------------------------------- | 
| 200 OK (INVITE) F1 | 
paaa | 
| ACK | 
ERR > 
INVITE (hold) /200 OK/ACK 
A TR RS AS A A A See > 


| 

| 

[REFER (Refer-To:sips:TransferTarget | 
?Replaces=dialog2) | 
| 

| 

| 

| 


INVITE (Replaces:dialog2)/200 OK/ACK F3 


NOTIFY (200 OK) 
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Figure 13: Semi-Attended Transfer as Attended Transfer Call Flow (Not 
Recommended) 


7.7. Attended Transfer Fallback to Basic Transfer 


In this flow, an attempted attended transfer fails so the Transferor 
falls back to basic transfer. 


The call flow in Figure 14 shows the use of Require: replaces in the 
INVITE sent by the Transferor to the Transfer Target in which the 
Transferor's intention at the time of sending the INVITE to the 
Transfer Target was known to be to complete an attended transfer. 
Since the Target does not support Replaces, the INVITE is rejected 
with a 420 Bad Extension response, and the Transferor switches from 
attended transfer to basic transfer immediately. 
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Transferor Transferee Transfer 
| | Target 
dialogl | INVITE/200 OK/ACK 
mS C | 
debct eios 0 NACE | 
Msc ead | 
ee 
dialog2 [ea pe TON | 
PEE ROSCA KAN AA BAN E ENE ERRONEA >| 
dialogl ks | 
dialog1 | 202 Accepted d 
deg pa | 
dialogi | E 00.06 
daaa MA | INVITE/200 OK/ACK | 
dialogl | NOTIFY (200 0K) | SES >| 
dialogi | NAG 200 og | 
dialogi | BYE/200 0K” | | 
dialog3 | i BYE/200 OK | 


Figure 14: Attended Transfer Fallback to Basic Transfer Using 
Require:replaces 


Figure 15 shows the use of OPTIONS when the Transferee and Transfer 
Target do not explicitly indicate support for the REFER method and 
Replaces header fields in Allow and Supported header fields and the 
Transferor did not have the intention of performing an attended 
transfer when the INVITE to the Target was sent. In dialogl, the 
Transferor determines, using OPTIONS, that the Transferee does 
support REFER and Replaces. As a result, the Transferor begins the 
attended transfer by placing the Transferee on hold and calling the 
Transfer Target. Using an OPTIONS in dialog2, the Transferor 
determines that the target does not support either REFER or Replaces, 
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making attended transfer impossible. The Transferor then ends 
dialog2 by sending a BYE then sends a REFER to the Transferee using 
the AOR URI of the Transfer Target. 


Transferor Transferee Transfer 
| | Target 
dialogl | INVITE/200 OK/ACK | 
a II eee ET | 
PM artis mara ong e | 
es | 
b EE A: >| 
Ma Pr ee i 
mE c PR MEHR J 


dialog3 | REFER (Target-Dialog:1, 
| Refer-To:sips:TransferTarget) 


| 
| 
| 
| 
SS SS Se EE EE > 
dialog3 | 202 Accepted 
a eee | | 
dialog3 | NOTIFY (100 Trying) | 
aa ae | 
dialog3 | 200 OK | 
NR Se an ye > 
dialog4 | INVITE/200 OK/ACK | 
[a naaa >| 
dialog3 | NOTIFY (200 OK) | | 
a aa | | 
dialog3 | 200 OK | 
tr ————— — Á ————— > 
dialogl | BYE/200 OK | 
e >| | 
dialog4 | | BYE/200 OK | 
| [fre | 


Figure 15: Attended Transfer Fallback to Basic Transfer 
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8. 


Transfer with Referred-By 


In the previous examples, the Transfer Target does not have 
definitive information about what party initiated the transfer, or, 
in some cases, even that transfer is taking place. The Referred-By 
mechanism [RFC3892] provides a way for the Transferor to provide the 
Transferee with a way to let the Transfer Target know what party 
initiated the transfer. 


The simplest and least secure approach just involves the inclusion of 
the Referred-By header field in the REFER, which is then copied into 
the triggered INVITE. However, a more secure mechanism involving the 
Referred-By security token, which is generated and signed by the 
Transferor and passed in a message body to the Transferee then to the 
Transfer Target. 


The call flow in Figure 16 shows the Referred-By header field and 
body in the REFER F5 and triggered INVITE F6. Note that the Secure/ 
Multipurpose Internet Mail Extensions (S/MIME) signature is not shown 
in the example below. The conventions used in the SIP Torture Test 
Messages [RFC4475] document are reused, specifically the «hex» and 
«allOneLine» tags. 
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Transferor Transferee Transfer 
| | Target 


dialogl 
dialogl 
dialog2 
dialog2 


dialog3 


dialog3 
dialog3 
dialog3 


dialog4 


dialog2 
dialog3 
dialog3 
dialogl 


dialog4 


| INVITE/200 OK/ACK F1 F2 


| <------------------- 
| INVITE (hold) /200 OK/ACK 
Eee m >| 
| INVITE/200 OK/ACK F3 F4 

a wx a y ure a ura a e a O a EM ae E > 
| INVITE (hold) /200 OK/ACK 
| ---------------------------------------- > 


| REFER (Target-Dialog:1, Referred-By:Transferor, 
| Refer-To:sips:TransferTarget?Replaces=2) 


F5 


| >| 
| 202 Accepted | 
< A A A er A a 
NOTIFY (100 Trying) 
| <------------------- 
| 200 OK | 
|------------------- >| 
| INVITE (Replaces:dialog2, 
| Referred-By:Transferor )/200 OK/ACK F6 
| ------------------- > 
| BYE/200 OK 
| La === 
| NOTIFY (200 OK) | 
|<------------------- | 
200 OK 
bok l 
| BYE/200 OK 
| d 
| | BYE/200 OK 
| |<------------------- 


Figure 16: Attended Transfer Call Flow with Referred-By 
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F5 REFER Transferor -> Transferee 


REFER sips:31d812adkjw@biloxi.example.com; gr=3413kj2ha SIP/2.0 
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch-z9hG4bK392039842 
Max-Forwards: 70 
To: «sips:31d812adkjwGbiloxi.example.com;gr-3413kj2hna» 
From: <sips:transferor@atlanta.example.com>;tag=1928301774 
Call-ID: a84b4c76e66710 
CSeq: 314160 REFER 
«allOneLine» 
Refer-To: <sips:482n4z24kdg@chicago.example.com; gr=8594958 
?Replaces-090459243588173445$3Bto-tag$3D9m2n3wq$3Bfrom-tag 
$3D763231&Require=replaces> 
</allOneLine> 
Supported: gruu, replaces, tdialog 
Require: tdialog 
Referred-By: <sips:transferor@atlanta.example.com> 

; cid="20398823.2UWOFN309shb3@atlanta.example.com" 
Target-Dialog: 592435881734450904;local-tag-9m2n3wq; remote-tag=763231 
Contact: <sips:4889445d8kjtk3@atlanta.example.com; gr=723jd2d> 
Content-Type: multipart/mixed; boundary=unique-boundary-1 
Content-Length: 


--unique-boundary-1 
Content-ID: <20398823.2UWOFN309shb3@atlanta.example.com> 


Content-Length: 2961 

Content-Type: multipart/signed; 
protocol="application/pkcs-7-signature"; 
micalg=shal; 
boundary="----590F24D439B31E08745DEF0CD9397189" 


Rie 590F24D439B31E08745DEF0CD9397189 
Content-Type: message/sipfrag 


Date: Thu, 18 Sep 2003 13:07:43 GMT 
«allOneLine» 
Refer-To: <sips:482n4z24kdg@chicago.example.com; gr=8594958 
?Replaces=090459243588173445%3B 
to-tag$3D9m2n3wq$3Bfrom-tag$3D763231&Require-replaces» 
«/allOneLine» 
Referred-By: <sips:transferor@atlanta.example.com> 

; cid-"20398823.20UWOFN309shb3Gatlanta.example.com" 


xu LES 590F24D439B31E08745DEF0CD9397189 
Content-Type: application/pkcs-7-signature; name-"smime.p7s" 
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Content-Transfer-Encoding: binary 
Content-Disposition: attachment; filename="smime.p7s" 


<hex>3082088806092A86 
4886F70D010702A082087930820875020101310B300906052B0E03021A050030 


(Signature not shown) 


8E63D306487A740A197A3970594CF47DD385643B1DC4 9FF767A3D2B428388966 
79089AAD95767F</hex> 


Re 590F24D439B31E08745DEF0CD9397189-- 


--unique boundary-1 


F6 INVITE Transferee -» Transfer Target 


INVITE sips:482n4z24kdg@chicago.example.com; gr=8594958 SIP/2.0 
Via: SIP/2.0/TLS referee.example;branch=z9hG4bkffe209934aac 
To: <sips:482n4z24kdg@chicago.example.com; gr=8594958> 

From: <sips:transferee@biloxi.example.com>;tag=2909034023 
Call-ID: fe9023940-a3465@referee.example 

CSeq: 889823409 INVITE 
Max-Forwards: 70 

Contact: <sips:31d812adkjw@biloxi.example.com; gr=3413k j2ha> 
Referred-By: <sips:transferor@atlanta.example.com> 
7 Cid="20398823.2UWOFN309shb3@atlanta.example.com" 

Replaces :090459243588173445; to-tag=9m2n3wq; from- 

tag=76323 

Require: replaces 

Supported: gruu, replaces, tdialog 

Content-Type: multipart/mixed; boundary=my-boundary-9 
Content-Length: 


--my-boundary-9 
Content-Type: application/sdp 


Content-Length: 156 


v-0 

o-referee 2890844526 2890844526 IN IP4 referee.example 
s=Session SDP 

C-IN IP4 referee.example 

t-0 0 

m-audio 49172 RTP/AVP 0 

a-rtpmap:0 PCMU/8000 
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--my-boundary-9 

Content-Length: 2961 

Content-Type: multipart/signed; 
protocol-"application/pkcs-7-signature"; 
micalg-shal; 
boundary="----590F24D439B31E08745DEF0CD9397189" 


SAS 590F24D439B31E08745DEF0CD9397189 
Content-Type: message/sipfrag 


Date: Thu, 18 Sep 2003 13:07:43 GMT 


<allOneLine> 
Refer-To: <sips:transfertarget@chicago.example.com; 
Replaces=090459243588173445%3B 
to-tag$3D9m2n3wq$3Bfrom-tag$3D763231&Require-replaces» 
«/allOneLine» 
Referred-By: <sips:transferor@atlanta.example.com> 

; cid-"20398823.20UWOFN309shb3Gatlanta.example.com" 


SRS 590F24D439B31E08745DEF0CD9397189 

Content-Type: application/pkcs-7-signature; name-"smime.p7s" 
Content-Transfer-Encoding: binary 

Content-Disposition: attachment; filename="smime.p7s" 


<hex>3082088806092A86 
4886F70D010702A082087930820875020101310B300906052B0E03021A050030 


(Signature not shown) 


8E63D306487A740A197A3970594CF47DD385643B1DC4 9FF767A3D2B428388966 
79089AAD95767F</hex> 


==-=--- 590F24D439B31E08745DEF0CD9397189-- 
--my-boundary-9-- 
9. Transfer as an Ad Hoc Conference 


In this flow, shown in Figure 17, Bob does an attended transfer of 
Alice to Carol. In order to keep both Alice and Carol fully informed 
of the nature and state of the transfer operation, Bob acts as a 
focus [RFC4579] and hosts an ad hoc conference involving Alice, Bob, 
and Carol. Alice and Carol subscribe to the conference package 
[RFC4575] of Bob's focus, which allows them to know the exact status 
of the operation. After the transfer operation is complete, Bob 
deletes the conference. 
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This call flow meets requirement 6 of Section 4. NOTIFY messages 
related to the refer package are indicated as NOTIFY (refer), while 
NOTIFYs related to the Conference Info package are indicated as 
NOTIFY (Conf-Info). 


Note that any type of semi-attended transfer in which media mixing or 
relaying could be implemented using this model. In addition to 
simply mixing, the focus could introduce additional media signals 
such as simulated ring tone or on hold announcements to improve the 
user experience. 


Alice Bob Carol 
| | | 
| INVITE | | 
|------------------- >| | 

180 Ringing | | 

< A a an m acit quei ii em a A Pe a SE 
| 200 OK | | 
| === | | 
| ACK | | 
| ES >| | 

RTP 

< > | 
| 


Bob places Alice on hold and begins acting like a focus 


| INVITE (hold) Contact :Conf-ID,isfocus 


| 
| | 
| | 
| | 
| | 
| Alice subscribes to the conference E 
| | 
| | 
| | 
| | 


eee > | 
200 OK 
En | 
NOTIFY (Conf-Info) 
< AA AA ag A i 
| 200 OK 


| | | 
— —€"—— ————!— > 
| 
| 


Bob begins consultation operation 


ee Require:replaces Contact:Conf-ID;isfocus 
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| 180 Ringing | 
| 


| 
| ——— | 
200 OK 

| ECT 
| | ACK | 
| |------------------- d 
| | RTP | 
| |< > | 


Carol subscribes to the conference package 
- learns Bob is on hold | 


[SUBSCRIBE sip:Conf-ID 
< 


NOTIFY (Conf-Info) 


Alice learns that Bob is talking to Carol 


| 
| 
—— | | 
| 


200 OK 
—————— > | 
INVITE (hold) 
EE > 
| 200 OK 
| <------------------- 
| ACK 


Bob begins transfer operation 


| 
| REFER Refer-To: Carol 
| 


N 
o 
o 
o 
A 


| NOTIFY (Refer) | 
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aaa >| | 
| 200 OK | | 
<------------------- | 
INVITE Replaces:B-C Contact:Alice 
| >| 
| 200 OK | 
(A coupe que | 
| ACK | 
— a a An A RE RR > 
RTP 
|< >| 
| | BYE | 
| nue e | 
| | 200 OK | 
| chc on >| 
| NOTIFY (Refer) | 
——————— md —— UN a me en] a > 
| 200 OK | | 
N | | 
| Bob terminates the ad-hoc conference | 
| BYE | 
| | | | 
| 200 OK | | 
aa eee REESE >| | 
| | NOTIFY (Conf-Info) | 
ren er ea AG oe er oe a > 
| | 200 OK 
| | <-=================> | 
| NOTIFY (Conf-Info) | | 
Pi c ee | | 
| 200 OK | | 
| oce d | 


Figure 17: Attended Transfer as an Ad Hoc Conference 


10. Transfer with Multiple Parties 


In this example, shown in Figure 18, 


the Facilitator who reaches the Recipient through the Screener. 


the Originator places a call to 
The 


Recipient's contact information is exposed to the Facilitator and the 


Originator. 
semantics of the REFER method only, 
design of an implementation. 
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and it should not be used as the 
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Originator Facilitator Screener Recipient 
| | 
INVITE/200 OK/ACK "Get Fred for me!" 
me > "Right away!" 
2 |INVITE (hold)/200 OK/ACK | | 
[e | | 
| INVITE/200 OK/ACK |"I have a call 
| cues > | | from Mary for Fred" 
INVITE (hold) /200 OK/ACK "Hold please" 
«----------- | 
| |INVITE/200 OK/ACK 
| |--------- >|"You have a call 
| | | £rom Mary" 
| | | "Put her through" 
| |INVITE (hold)/200 OK/ACK 
--------- > 
mS | | 
| <----------- | | 
[202 Accepted | | 
|----------- >| | 
|NOTIFY (100 Trying) | 
----------- > 
200 OK | 
|<----------- | | 
| INVITE/200 OK/ACK | 
aorta AA ee ae >|"This is Fred" 
[NOTIFY (200 OK) | "Please hold for 
A MICE IO, ad > Mary" 
200 OK 
Ie | | 
|BYE/200 OK | | 
| <----------- | | 
| |BYE/200 OK| 
|--------- >| 
INVITE (hold) /200 OK/ACK 
| > >| 
REFER | | | 
—— | | | 
202 Accepted | | 
PG >| 
NOTIFY (100 Trying) 
pa >| | | 
200 OK | | | 
|<----------- | | 
7  |INVITE/200 OK/ACK | | 
POSTS TSS 2=S=== > | "Hey Fred" 
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11. 


li 


6  |NOTIFY (200 OK) | "Hello Mary" 
| 


| 
eae nian >| | 
6 |200 OK 
nla M | 
1 |BYE/200 OK | | | 
a DE | | | 
5: || |BYE/200 OK | | 
| A >| 
7 |BYE/200 OK | | 
RUSS SPS TSS STS SSS SS See ape SSS "See you later" 


Figure 18: Transfer with Multiple Parties Example 
Gateway Transfer Issues 


A gateway in SIP acts as a User Agent. As a result, the entire 
preceding discussion and call flows apply equally well to gateways as 
native SIP endpoints. However, there are some gateway-specific 
issues that are documented in this section. While this discussion 
focuses on the common cases involving Public Switched Telephone 
Network (PSTN) gateways, similar situations exist for other gateways, 
such as H.323/SIP gateways. 


.1. Coerce Gateway Hairpins to the Same Gateway 


To illustrate how a hairpin situation can occur in transfer, consider 
this example. The original call dialog is setup with the Transferee 
residing on the PSTN side of a SIP gateway. The Transferor is a SIP 
phone purely in the IP space. The Transfer Target is on the PSTN 
side of a SIP gateway as well. After completing the transfer, 
(regardless of consultative or blind) the Transferee is in a call 
with the Transfer Target (both on the PSTN side of a gateway). It is 
often desirable to remove the gateway(s) out of the loop. This is 
likely to only be possible if both legs of the target call are on the 
same gateway. With both legs on the same gateway, it may be able to 
invoke the analogous transfer on the PSTN side. Then the target call 
would not involve the gateway. 


So the problem is how to give the proxy enough information so that it 
knows to route the call to the same gateway. With a simple single 
call that hairpins, the incoming and outgoing leg have the same 
dialog. The proxy should have enough information to optimize the 
routing. 


In the consultative transfer scenario, it is desirable to coerce the 
consultative INVITE out the same gateway as the original call to be 
transferred. However, there is no way to relate the consultation 
with the original call. In the consultative case, the target call 
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12: 


INVITE includes the Replaces header, which contains dialog 
information that can be used to relate it to the consultation. 
However, there is no information that relates the target call to the 
original. 


In the blind transfer scenario, it is desirable to coerce the target 
call onto the same gateway as the original call. However, the same 
problem exists in that the target-dialog cannot be related to the 
original dialog. 


In either transfer scenario, it may be desirable to push the transfer 
operation onto the non-SIP side of the gateway.  Presumably, this is 
not possible unless all of the legs go out the same gateway. If the 
gateway supports more than one trunk group, it might also be 
necessary to get all of the legs on the same trunk group in order to 
perform the transfer on the non-SIP side of the gateway. 


Solutions to these gateway specific issues may involve new extensions 
to SIP in the future. 


-2. Consultative Turned Blind Gateway Glare 


In the consultative transfer case turned blind, there is a glare-like 
problem. The Transferor initiates the consultation INVITE, the 
Transferor gets impatient and hangs up, transitioning this to a blind 
transfer. The Transfer Target on the gateway (connected through a 
PSTN switch to a single line or dumb analog phone) rings. The user 
answers the phone just after the CANCEL is received by the Transfer 
Target. The REFER and INVITE for the target call are sent. The 
Transferee attempts to set up the call on the PSTN side, but gets 
either a busy response or lands in the users voicemail as the user 
has the handset in hand and off hook. 


This is another example of a race condition that this call flow can 
cause. The recommended behavior is to use the approach described in 
Section 7.6. 


Security Considerations 


The call transfer flows shown in this document are implemented using 
the REFER and Replaces call control primitives in SIP. As such, the 
security considerations detailed in the REFER [RFC3515] and Replaces 
[RFC3891] documents MUST be followed, which are briefly summarized in 
the following paragraphs. This document addresses the issue of 
protecting the Address of Record URI of a Transfer Target in Sections 
7.1 and 7.2. 
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14. 


Any REFER request MUST be appropriately authenticated and authorized 
using standard SIP mechanisms or else calls may be hijacked. A User 
Agent may use local policy or human intervention in deciding whether 
or not to accept a REFER. In generating NOTIFY responses based on 
the outcome of the triggered request, care should be taken in 
constructing the message/sipfrag body to ensure that no private 
information is leaked. 


An INVITE containing a Replaces header field SHOULD only be accepted 
if it has been properly authenticated and authorized using standard 
SIP mechanisms, and the requestor is authorized to perform dialog 
replacement. Special care is needed if the replaced dialog utilizes 
additional media streams compared to the original dialog. In this 
case, the user MUST authorize the addition of new media streams in a 
dialog replacement. For example, the same mechanism used to 
authorize the addition of a media stream in a re-INVITE could be 
used. 
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